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Abstract 


The ITU-T has defined an architecture and requirements for operating 
an Automatically Switched Optical Network (ASON). 


The Generalized Multiprotocol Label Switching (GMPLS) protocol suite 
is designed to provide a control plane for a range of network 
technologies. These include optical networks such as time division 
multiplexing (TDM) networks including the Synchronous Optical 
Network/Synchronous Digital Hierarchy (SONET/SDH), Optical Transport 
Networks (OTNs), and lambda switching optical networks. 


The requirements for GMPLS routing to satisfy the requirements of 
ASON routing and an evaluation of existing GMPLS routing protocols 
are provided in other documents. This document defines extensions to 
the OSPFv2 Link State Routing Protocol to meet the requirements for 
routing in an ASON. 


Note that this work is scoped to the requirements and evaluation 
expressed in RFC 4258 and RFC 4652 and the ITU-T Recommendations that 
were current when those documents were written. Future extensions or 
revisions of this work may be necessary if the ITU-T Recommendations 
are revised or if new requirements are introduced into a revision of 
RFC 4258. This document obsoletes RFC 5787 and updates RFC 5786. 
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Status of This Memo 
This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 
and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc6827. 


Copyright Notice 


Copyright (c) 2013 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. Code Components extracted from this document must 
include Simplified BSD License text as described in Section 4.e of 
the Trust Legal Provisions and are provided without warranty as 
described in the Simplified BSD License. 
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Les 


Introduction 


The Generalized Multiprotocol Label Switching (GMPLS) [RFC3945] 
protocol suite is designed to provide a control plane for a range of 
network technologies. These include optical networks such as time 
division multiplexing (TDM) networks including SONET/SDH, Optical 
Transport Networks (OTNs), and lambda switching optical networks. 


The ITU-T defines the architecture of the Automatically Switched 
Optical Network (ASON) in [G.8080]. 


[RFC4258] describes the routing requirements for the GMPLS suite of 
routing protocols to support the capabilities and functionality of 
ASON control planes identified in [G.7715] and in [G.7715.1]. 


[RFC4652] evaluates the IETF Link State routing protocols against the 
requirements identified in [RFC4258]. Section 7.1 of [RFC4652] 
summarizes the capabilities to be provided by OSPFv2 [RFC2328] in 
support of ASON routing. This document describes the OSPFv2 
specifics for ASON routing. 


Multi-layer transport networks are constructed from multiple networks 
of different technologies operating in a client-server relationship. 
The ASON routing model includes the definition of routing levels that 
provide scaling and confidentiality benefits. In multi-level 
routing, domains called routing areas (RAs) are arranged in a 
hierarchical relationship. Note that as described in [RFC4652], 
there is no implied relationship between multi-layer transport 
networks and multi-level routing. The multi-level routing mechanisms 
described in this document work for both single-layer and multi-layer 
networks. 


Implementations may support a hierarchical routing topology (multi- 
level) for multiple transport network layers and/or a hierarchical 
routing topology for a single transport network layer. 


This document describes the processing of the generic (technology- 
independent) link attributes that are defined in [RFC3630], 
[RFC4202], and [RFC4203] and that are extended in this document. As 
described in Section 5.2, technology-specific traffic engineering 
attributes and their processing may be defined in other documents 
that complement this document. 
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Note that this work is scoped to the requirements and evaluation 
expressed in [RFC4258] and [RFC4652] and the ITU-T Recommendations 
that were current when those documents were written. Future 
extensions or revisions of this work may be necessary if the ITU-T 
Recommendations are revised or if new requirements are introduced 
into a revision of [RFC4258]. 


1.1. Conventions Used in This Document 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 


"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [RFC2119]. 


The reader is assumed to be familiar with the terminology and 
requirements developed in [RFC4258] and the evaluation outcomes 
described in [RFC4652]. 


General ASON terminology is provided in Appendix A. ASON routing 
terminology is described in Appendix B. 


2. Routing Areas, OSPF Areas, and Protocol Instances 


An ASON routing area (RA) represents a partition of the transport 
plane, and its identifier is used within the control plane as the 
representation of this partition. 


RAs are hierarchically contained: a higher-level (parent) RA contains 
lower-level (child) RAs that in turn MAY also contain RAs. Thus, RAs 
contain RAs that recursively define successive hierarchical RA 
levels. Routing information may be exchanged between levels of the 
RA hierarchy, i.e., Level N+1 and N, where Level N represents the RAs 
contained by Level N+1. The links connecting RAs may be viewed as 
external links (inter-RA links), and the links representing 
connectivity within an RA may be viewed as internal links (intra-RA 
links). The external links to an RA at one level of the hierarchy 
may be internal links in the parent RA. Intra-RA links of a child RA 
MAY be hidden from the parent RA’s view [RFC4258]. 


An ASON RA can be mapped to an OSPF area, but the hierarchy of ASON 
RA levels does not map to the hierarchy of OSPF areas. Instead, 
successive hierarchical levels of RAs MUST be represented by separate 
instances of the protocol. Thus, inter-level routing information 
exchange (as described in Section 7) involves the export and import 
of routing information between protocol instances. 
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An ASON RA may therefore be identified by the combination of its OSPF 
Instance ID and its OSPF Area ID. With proper and careful network- 
wide configuration, this can be achieved using just the OSPF Area ID, 
and this process is RECOMMENDED in this document. These concepts are 
discussed in Section 7. 


A key ASON requirement is the support of multiple transport planes or 
layers. Each transport node has associated topology (links and 
reachability), which is used for ASON routing. 


3. Terminology and Identification 
This section describes the mapping of key ASON entities to OSPF 


entities. Appendix A contains a complete glossary of ASON routing 
terminology. 


There are three categories of identifiers used for ASON routing 
(G.7715.1): transport-plane names, control-plane identifiers for 
components, and Signaling Communications Network (SCN) addresses. 
This section discusses the mapping between ASON routing identifiers 
and corresponding identifiers defined for GMPLS routing and how these 
support the physical (or logical) separation of transport-plane 
entities and control-plane components. GMPLS supports this 
separation of identifiers and planes. 


In the context of OSPF Traffic Engineering (TE), an ASON transport 
node corresponds to a unique OSPF TE node. An OSPF TE node is 
uniquely identified by the TE Router Address TLV [RFC3630]. In this 
document, the TE Router Address is referred to as the TE Router ID. 
In GMPLS, TE router addresses are advertised as reachable in both the 
control and transport planes, see Section 4 below. Furthermore, the 
TE Router ID should not be confused with the OSPF Router ID that 
uniquely identifies an OSPF router within an OSPF routing domain 
[RFC2328] and is in a name space for control-plane components. 


The Router Address top-level TLV definition, processing, and usage 
are largely unchanged from [RFC3630]. This TLV specifies a stable 
OSPF TE node IP address, i.e., the IP address is always reachable 
when there is IP connectivity to the associated OSPF TE node. 


ASON defines a Routing Controller (RC) as an entity that handles 
(abstract) information needed for routing and the routing information 
exchange with peering RCs by operating on the Routing Database (RDB). 
ASON defines a Protocol Controller (PC) as an entity that handles 
protocol-specific message exchanges according to the reference point 
over which the information is exchanged (e.g., E-NNI, I-NNI) and 
internal exchanges with the RC [RFC4258]. In this document, an OSPF 
router advertising ASON TE topology information will perform both the 
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functions of the RC and PC. The OSPF routing domain comprises the 
control plane, and each OSPF router is uniquely identified by its 
OSPF Router ID [RFC2328]. 


4. Reachability 


In ASON, reachability information describes the set of endpoints that 
are reachable by the associated node in the transport plane. 
Reachability information represents transport-plane resources, e.g., 
an optical cross-connect interface, and uses transport-plane 
identifiers. 


In order to advertise blocks of reachable address prefixes, a 
summarization mechanism is introduced that is based on the techniques 
described in [RFC5786]. For ASON reachability advertisement, blocks 
of reachable address prefixes are advertised together with the 
associated transport-plane node. The transport-plane node is 
identified in OSPF TE Link State Advertisements (LSAs) by its TE 
Router ID, as discussed in Section 6. 


In order to support ASON reachability advertisement, the Node 
Attribute TLV defined in [RFC5786] is used to advertise the 
combination of a TE Router ID and its set of associated reachable 
address prefixes. The Node Attribute TLV can contain the following 
sub-TLVs: 


- Local TE Router ID sub-TLV: Length: 4; Defined in Section 6.2 
- Node IPv4 Local Address sub-TLV: Length: variable; [RFC5786] 
- Node IPv6 Local Address sub-TLV: Length: variable; [RFC5786] 


A router may support multiple transport nodes as discussed in 

Section 6 and, as a result, may be required to advertise reachability 
separately for each transport node. As a consequence, it MUST be 
possible for the router to originate more than one TE LSA containing 
the Node Attribute TLV when used for ASON reachability advertisement. 


Hence, the Node Attribute TLV [RFC5786] advertisement rules are 
relaxed. A Node Attribute TLV MAY appear in more than one TE LSA 
originated by the RC when the RC is advertising reachability 
information for a different transport node identified by the Local TE 
Router sub-TLV (refer to Section 6.2). 


As specified in [RFC3630], TE-advertised router addresses are also 


advertised as reachable in the control plane and are therefore also 
valid identifiers in the ASON SCN name space. 
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5. Link Attribute 


With the exception of local adaptation (described below), the mapping 
of link attributes and characteristics to OSPF TE Link TLV sub-TLVs 
is unchanged [RFC4652]. OSPF TE Link TLV sub-TLVs are described in 
[RFC3630] and [RFC4203]. Advertisement of this information SHOULD be 
supported on a per-layer basis, i.e., one TE LSA per unique switching 
capability and bandwidth granularity combination. 


5.1. Local Adaptation 


Local adaptation is defined as a TE link attribute (i.e., sub-TLV) 
that describes the cross/inter-layer relationships. 


The Interface Switching Capability Descriptor (ISCD) TE Attribute 
[RFC4202] identifies the ability of the TE link to support cross- 
connection to another link within the same layer. When advertising 
link adaptation, it also identifies the ability to use a locally 
terminated connection that belongs to one layer as a data link for 
another layer (adaptation capability). However, the information 
associated with the ability to terminate connections within that 
layer (referred to as the termination capability) is advertised with 
the adaptation capability. 


For instance, a link between two optical cross-connects will contain 
at least one ISCD attribute describing the Lambda Switching Capable 
(LSC) switching capability. Conversely, a link between an optical 
cross-connect and an IP/MPLS Label Switching Router (LSR) will 
contain at least two ISCD attributes, one for the description of the 
LSC termination capability and one for the Packet Switching Capable 
(PSC) adaptation capability. 


In OSPFv2, the Interface Switching Capability Descriptor (ISCD) is a 
sub-TLV (type 15) of the top-level Link TLV (type 2) [RFC4203]. The 
adaptation and termination capabilities are advertised using two 
separate ISCD sub-TLVs within the same top-level Link TLV. 


An interface MAY have more than one ISCD sub-TLV, per [RFC4202] and 


[RFC4203]. Hence, the corresponding advertisements should not result 
in any compatibility issues. 
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5.2. Bandwidth Accounting 


GMPLS routing defines an ISCD that provides, among other things, the 
quantities of the maximum/minimum available bandwidth per priority 
for Label Switched Paths (LSPs). One or more ISCD sub-TLVs can be 
associated with an interface, per [RFC4202] and [RFC4203]. This 
information, combined with the Unreserved Bandwidth Link TLV sub-TLV 
[RFC3630], provides the basis for bandwidth accounting. 


In the ASON context, additional information may be included when the 
representation and information in the other advertised fields are not 
sufficient for a specific technology, e.g., SDH. The definition of 

technology-specific information elements is beyond the scope of this 


document. Some technologies will not require additional information 
beyond what is already defined in [RFC3630], [RFC4202], and 
[RFC4203]. 


6. Routing Information Scope 


For ASON routing, the control-plane component routing adjacency 
topology (i.e., the associated Protocol Controller (PC) connectivity) 
and the transport topology are not assumed to be congruent [RFC4258]. 
Hence, a single OSPF router (i.e., the PC) MUST be able to advertise 
on behalf of multiple transport-layer nodes. The OSPF routers are 
identified by OSPF Router ID, and the transport nodes are identified 
by TE Router ID. 


The Router Address TLV [RFC3630] is used to advertise the TE Router 
ID associated with the advertising Routing Controller (RC). TE 
Router IDs for additional transport nodes are advertised through 
specification of the Local TE Router Identifier in the Local and 
Remote TE Router TE sub-TLV and the Local TE Router Identifier 
sub-TLV described in the sections below. These Local TE Router 
Identifiers are typically used as the local endpoints for TE LSPs 
terminating on the associated transport node. 


The use of multiple OSPF Routers to advertise TE information for the 
same transport node is not considered a required use case and is not 
discussed further in this document. 


6.1. Link Advertisement (Local and Remote TE Router ID Sub-TLV) 


When an OSPF Router advertises on behalf of multiple transport nodes, 
the link endpoints cannot be automatically assigned to a single 
transport node associated with the advertising router. In this case, 
the local and remote transport nodes MUST be identified by TE Router 
ID to unambiguously specify the transport topology. 
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For this purpose, a new sub-TLV of the OSPFv2 TE LSA top-level Link 
TLV is introduced that defines the Local and Remote TE Router ID. 


The Type field of the Local and Remote TE Router ID sub-TLV is 
assigned the value 10 (see Section 10). The Length field takes the 
value 8. The Value field of this sub-TLV contains 4 octets of the 
Local TE Router Identifier followed by 4 octets of the Remote TE 
Router Identifier. The value of the Local and Remote TE Router 
Identifier MUST NOT be set to 0. 


The format of the Local and Remote TE Router ID sub-TLV is: 


0 1 2 3 
0123456789012345678909012345678090m1 
o II 
Type (10) | Length (8) | 
II 
Local TE Router Identifier | 
—f-4-4+-4-4-4-4-4-4-4-4- o FF FHF fF tt H+ 
Remote TE Router Identifier | 
-f-4-4+-4-4-4-4-4-4F-4-4- 4-4 o FHF FF $F Ft Ht 


+—+—4+—+4+ 


This sub-TLV MUST be included as a sub-TLV of the top-level Link TLV 
if the OSPF router is advertising on behalf of one or more transport 
nodes having TE Router IDs different from the TE Router ID advertised 
in the Router Address TLV. For consistency, this sub-TLV MUST be 
included when OSPF is used for the advertisement of ASON information 
as described herein. If it is not included in a Link TLV, or if a 
value of 0 is specified for the Local or Remote TE Router Identifier, 
the Link TLV will not be used for transport-plane path computation. 
Additionally, the condition SHOULD be logged for possible action by 
the network operator. 


Note: The Link ID sub-TLV identifies the other end of the link (i.e., 
Router ID of the neighbor for point-to-point links) [RFC3630]. When 
the Local and Remote TE Router ID sub-TLV is present, it MUST be used 
to identify local and remote transport node endpoints for the link 
and the Link-ID sub-TLV MUST be ignored. In fact, when the Local and 
Remote TE Router ID sub-TLV is specified, the Link-ID sub-TLV MAY be 
omitted. The Local and Remote TE Router ID sub-TLV, if specified, 
MUST only be specified once. If specified more than once, instances 
other than the first will be ignored and the condition SHOULD be 
logged for possible action by the network operator. 


Malis, et al. Standards Track [Page 10] 


RFC 6827 ASON Routing for OSPFv2 Protocols January 2013 


6.2. Reachability Advertisement (Local TE Router ID Sub-TLV) 


When an OSPF router is advertising on behalf of multiple transport 
nodes, the routing protocol MUST be able to associate the advertised 
reachability information with the correct transport node. 


For this purpose, a new sub-TLV of the OSPFv2 TE LSA top-level Node 
Attribute TLV is introduced. This TLV associates the local prefixes 
(see above) to a given transport node identified by the TE Router ID. 


The Type field of the Local TE Router ID sub-TLV is assigned the 
value 5 (see Section 10). The Length field takes the value 4. The 
Value field of this sub-TLV contains the Local TE Router Identifier 
encoded over 4 octets. 


The format of the Local TE Router ID sub-TLV is: 


0 db 2 3 
01234567890123456789012345678090m1 
e E EAE 
| Type (5) | Length (4) | 
ORAS E E haa a ee ea oe E eet E 

| Local TE Router Identifier 
pie Sn eee et er cme ee ee ee nr see eee E eer a ee eo eee ee ee ees ee ree ee 


This sub-TLV MUST be included as a sub-TLV of the top-level Node 
Attribute TLV if the OSPF router is advertising on behalf of one or 
more transport nodes having TE Router IDs different from the TE 
Router ID advertised in the Router Address TLV. For consistency, 
this sub-TLV MUST be included when OSPF is used for the advertisement 
of ASON information as described herein. If it is not included in a 
Node Attribute TLV, or if a value of 0 is specified for the Local TE 
Router Identifier, the Note Attribute TLV will not be used for 
determining ASON SCN reachability. Additionally, the condition 
SHOULD be logged for possible action by the network operator. 


7. Routing Information Dissemination 


An ASON routing area (RA) represents a partition of the transport 
plane, and its identifier is used within the control plane as the 
representation of this partition. An RA may contain smaller RAs 
inter-connected by links. ASON RA levels do not map directly to OSPF 
areas. Rather, hierarchical levels of RAs are represented by 
separate OSPF protocol instances. However, it is useful to align the 
RA IDs and area ID in order to facilitate isolation of RAs as 
described in Section 11.1. 


Malis, et al. Standards Track [Page 11] 


RFC 6827 ASON Routing for OSPFv2 Protocols January 2013 


Routing Controllers (RCs) supporting multiple RAs disseminate 
information downward and upward in this ASON hierarchy. The vertical 
routing information dissemination mechanisms described in this 
section do not introduce or imply hierarchical OSPF areas. RCs 
supporting RAs at multiple levels are structured as separate OSPF 
instances with routing information exchange between levels described 
by import and export rules between these instances. The 
functionality described herein does not pertain to OSPF areas or OSPF 
Area Border Router (ABR) functionality. 


7.1. Import/Export Rules 


RCs supporting RAs disseminate information upward and downward in the 
hierarchy by importing/exporting routing information as TE LSAs. TE 
LSAs are area-scoped Opaque LSAs with Opaque type 1 [RFC3630]. The 
information that MAY be exchanged between adjacent levels includes 
the Router Address, Link, and Node Attribute top-level TLVs. 


The imported/exported routing information content MAY be transformed, 
e.g., filtered or aggregated, as long as the resulting routing 
information is consistent. In particular, when more than one RC is 
bound to adjacent levels and both are allowed to import/export 
routing information, it is expected that these transformations are 
performed in a consistent manner. Definition of these policy-based 
mechanisms are outside the scope of this document. 


In practice, and in order to avoid scalability and processing 
overhead, routing information imported/exported downward/upward in 
the hierarchy is expected to include reachability information (see 
Section 4) and, upon strict policy control, link topology 
information. 


7.2. Loop Prevention 


When more than one RC is bound to an adjacent level of the ASON 
hierarchy and is configured to export routing information upward or 
downward, a specific mechanism is required to avoid looping of 
routing information. Looping is the re-advertisement of routing 
information into an RA that had previously advertised that routing 
information upward or downward into an upper or lower level RA in the 
ASON hierarchy. For example, without loop-prevention mechanisms, 
this could happen when the RC advertising routing information 
downward in the hierarchy is not the same one that advertises routing 
information upward in the hierarchy. 
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7.2.1. Inter-RA Export Upward/Downward Sub-TLVs 


The Inter-RA Export sub-TLVs can be used to prevent the 
re-advertisement of OSPF TE routing information into an RA that 
previously advertised that information. The type value 13 (see 
Section 10) will indicate that the associated routing information has 
been exported downward. The type value 12 (see Section 10) will 
indicate that the associated routing information has been exported 
upward. While it is not required for routing information exported 
downward, both sub-TLVs will include the Routing Area (RA) ID from 
which the routing information was exported. This RA is not 
necessarily the RA originating the routing information but the RA 
from which the information was immediately exported. 


These additional sub-TLVs MAY be included in TE LSAs that include any 
of the following top-level TLVs: 


- Router Address top-level TLV 
- Link top-level TLV 
- Node Attribute top-level TLV 


The Type field of the Inter-RA Export Upward and Inter-RA Export 
Downward sub-TLVs are respectively assigned the values 12 and 13 (see 
Section 10). The Length field in these sub-TLVs takes the value 4. 
The Value field in these sub-TLVs contains the associated RA ID. The 
RA ID value must be a unique identifier for the RA within the ASON 
routing domain. 


The format of the Inter-RA Export Upward and Inter-RA Export Downward 
sub-TLVs is graphically depicted below: 


0 1 2 3 
012345678901 23456789012345678090 1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| Upward/Downward Type | Length (4) 

| (12/13) | | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Associated RA ID | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


7.2.2. Inter-RA Export Upward/Downward Sub-TLV Processing 


TE LSAs MAY be imported or exported downward or upward in the ASON 
routing hierarchy. The direction and advertising RA ID are 
advertised in an Inter-RA Export Upward/Downward sub-TLV. They MUST 
be retained and advertised in the receiving RA with the associated 
routing information. 
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When exporting routing information upward in the ASON routing 
hierarchy, any information received from a level above, i.e., tagged 
with an Inter-RA Export Downward sub-TLV, MUST NOT be exported 
upward. Since an RA at Level N is contained by a single RA at 

Level N+1, this is the only checking that is necessary and the 
associated RA ID is used solely for informational purposes. 


When exporting routing information downward in the ASON routing 
hierarchy, any information received from a level below, i.e., tagged 
with an Inter-RA Export Upward sub-TLV, MUST NOT be exported downward 
if the target RA ID matches the RA ID associated with the routing 
information. This additional checking is required for routing 
information exported downward since a single RA at Level N+1 may 
contain multiple RAs at Level N in the ASON routing hierarchy. In 
other words, routing information MUST NOT be exported downward into 
the RA from which it was received. 


8. OSPFv2 Scalability 


The extensions described herein are only applicable to ASON routing 
domains, and it is not expected that the attendant reachability (see 
Section 4) and link information will ever be combined with global 
Internet or Layer 3 Virtual Private Network (VPN) routing. If there 
were ever a requirement for a given RC to participate in both 
domains, separate OSPFv2 instances would be utilized. However, ina 
multi-level ASON hierarchy, the potential volume of information could 
be quite large and the recommendations in this section MUST be 
followed by RCs implementing this specification. 


- Routing information exchange upward/downward in the hierarchy 
between adjacent RAs MUST, by default, be limited to reachability 
information. In addition, several transformations such as prefix 
aggregation are RECOMMENDED to reduce the amount of information 
imported/exported by a given RC when such transformations will not 
impact consistency. 


- Routing information exchange upward/downward in the ASON hierarchy 
involving TE attributes MUST be under strict policy control. 
Pacing and min/max thresholds for triggered updates are strongly 
RECOMMENDED. 


- The number of routing levels MUST be maintained under strict policy 
control. 
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Security Considerations 


This document specifies the contents and processing of OSPFv2 TE LSAs 
[RFC3630] and [REC4202]. The TE LSA extensions defined in this 
document are not used for Shortest Path First (SPF) computation and 
have no direct effect on IP routing. Additionally, ASON routing 
domains are delimited by the usual administrative domain boundaries. 


E 


Any mechanisms used for securing the exchange of normal OSPF LSAs can 
be applied equally to all TE LSAs used in the ASON context. 
Authentication of OSPFv2 LSA exchanges (such as OSPF cryptographic 
authentication [RFC2328] [RFC5709]) can be used to provide 
significant protection against active attacks. [RFC5709] defines a 
mechanism for authenticating OSPFv2 packets by making use of the 
Hashed Message Authentication Code (HMAC) algorithm in conjunction 
with the SHA family of cryptographic hash functions. 


RCs implementing export/import of ASON routing information between 
RAs MUST also include policy control of both the maximum amount of 
information advertised between RAs and the maximum rate at which it 
is advertised. This is to isolate the consequences of an RC being 
compromised to the RAs to which that subverted RC is attached. 


The "Analysis of OSPF Security According to KARP Design Guide" 
[OSPF-SEC] provides a comprehensive analysis of OSPFv2 and OSPFv3 
security relative to the requirements specified in [RFC6518]. 


IANA Considerations 
This document defines new sub-TLVs for inclusion in OSPF TE LSAs. 
IANA has assigned values per the assignment policies for the 
registries of code points for these sub-TLVs [RFC3630]. 
The following subsections summarize the required sub-TLVs. 


do: Sub-TLVs of the Link TLV 


This document defines the following sub-TLVs of the Link TLV 
advertised in the OSPF TE LSA: 


- Local and Remote TE Router ID sub-TLV (10) 
—- Inter-RA Export Upward sub-TLV (12) 
- Inter-RA Export Downward sub-TLV (13) 


Codepoints for these sub-TLVs have been allocated in the Standards 
Action range of the "Types for sub-TLVs of TE Link TLV (Value 2)" 
registry [RFC3630]. 
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Note that the same values for the Inter-RA Export Upward sub-TLV and 
the Inter-RA Export Downward sub-TLV MUST be used when they appear in 
the Link TLV, Node Attribute TLV, and Router Address TLV. 


-2. Sub-TLVs of the Node Attribute TLV 


This document defines the following sub-TLVs of the Node Attribute 
TLV advertised in the OSPF TE LSA: 


- Local TE Router ID sub-TLV (5) 
- Inter-RA Export Upward sub-TLV (12) 
- Inter-RA Export Downward sub-TLV (13) 


Codepoints for these sub-TLVs have been assigned in Standards Action 
range of the "Types for sub-TLVs of TE Node Attribute TLV (Value 5)" 
[RFC5786]. 


Note that the same values for the Inter-RA Export Upward sub-TLV and 
the Inter-RA Export Downward sub-TLV MUST be used when they appear in 
the Link TLV, Node Attribute TLV, and Router Address TLV. 


3. Sub-TLVs of the Router Address TLV 


The Router Address TLV is advertised in the OSPF TE LSA [RFC3630]. 
Since the TLV had no sub-TLVs defined, a "Types for sub-TLVs of 
Router Address TLV (Value 1)" registry has been defined. 


The registry guidelines for the assignment of types for sub-TLVs of 
the Router Address TLV are as follows: 


o Types in the range 0-32767 are to be assigned via Standards 
Action. 


o Type 0 in the aforementioned Standards Action range (0-32767) 
is reserved. 


o Types in the range 32768-32777 are for experimental use; these 
will not be registered with IANA and MUST NOT be mentioned by 
RFCs. 


o Types in the range 32778-65535 are not to be assigned at this 
time. Before any assignments can be made in this range, there 
MUST be a Standards Track RFC that specifies IANA 
Considerations that covers the range being assigned. 
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This document defines the following sub-TLVs for inclusion in the 
Router Address TLV: 


- Inter-RA Export Upward sub-TLV (12) 
- Inter-RA Export Downward sub-TLV (13) 


Codepoints for these sub-TLVs have been allocated in the Standards 
Action range of the "Types for sub-TLVs of Router Address TLV 
(Value 1)" registry. 


Note that the same values for the Inter-RA Export Upward sub-TLV and 
the Inter-RA Export Downward sub-TLV MUST be used when they appear in 
the Link TLV, Node Attribute TLV, and Router Address TLV. 


Management Considerations 
1. Routing Area (RA) Isolation 


If the RA ID is mapped to the OSPF Area ID as recommended in 
Section 2, OSPF [RFC2328] implicitly provides isolation. On any 
intra-RA link, packets will only be accepted if the area ID in the 
OSPF packet header matches the area ID for the OSPF interface on 
which the packet was received. Hence, RCs will only establish 
adjacencies and exchange reachability information (see Section 4.0) 
with RCs in the same RA. Other mechanisms for RA isolation are 
beyond the scope of this document. 


.2. Routing Area (RA) Topology/Configuration Changes 


The GMPLS Routing for ASON requirements [RFC4258] dictate that the 
routing protocol MUST support reconfiguration and SHOULD support 
architectural evolution. OSPF [RFC2328] includes support for the 
dynamic introduction or removal of ASON reachability information 
through the flooding and purging of OSPF Opaque LSAs [RFC5250]. 

Also, when an RA is partitioned or an RC fails, stale LSAs SHOULD NOT 
be used unless the advertising RC is reachable. The configuration of 
OSPF RAs and the policies governing the redistribution of ASON 
reachability information between RAs are implementation issues 
outside of the OSPF routing protocol and beyond the scope of this 
document. 


Comparison to Requirements in RFC 4258 


The following table shows how this document complies with the 
requirements in [RFC4258]. The first column contains a requirements 
number (1-30) and the relevant section in RFC 4258. The second 
column describes the requirement, the third column discusses the 
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compliance to that requirement, and the fourth column lists the 
relevant section in this document and/or another RFC that already 
satisfies the requirement. 
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+—--------------------------- +--------------- 
RFC 4258 Requirement Compliance 
A a 
| The failure of an RC, or | Implied by 

| the failure of | separation of 
communications between RCs, | transport and 
and the subsequent recovery|control plane. 

| from the failure condition | 

| MUST NOT disrupt calls in | 

| progress. | 
Hon +--------------- 
| | 


Multiple Hierarchical 
Levels of ASON Routing 
Areas (RAs). 


communications, RCs MUST maps to OSPF 
verify that they are bound Area ID. 

to the same parent RA. Otherwise, 
out of scope. 


+ + 
| Prior to establishing | Yes, when RA 
| | 
| | 


+ + 
| The RC ID MUST be unique | Yes 
| | 
+ + 


within its containing RA. 


Each RA within a carrier’s 

network SHALL be uniquely 
| identifiable. RA IDs MAY |the operator’s 
| be associated with a |responsibility. 
| 


Yes - although 
uniqueness is 


transport-plane name space, | 

whereas RC IDs are | 
associated with a 

control-plane name space. 


Information Dissemination. 


+ + 
| Hierarchical Routing | Yes 
| | 
+ + 


Routing Information 
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| and N+1 via separate | 
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| import/export. | 
+ + 
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| Routing Information No - Not 
exchanged between levels N 
and N+1 via external link 


(inter-RA links). 


exchange MUST include 
reachability information 
and MAY include, upon 
policy decision, node and 
link topology. 


There SHOULD NOT be any 
dependencies on the 
different routing protocols 
used within an RA or in 
different RAs. 


+ 
| 
| 
+ 
Routing information | Yes 
| 
| 
| 
+ 
| 
| 


instances. 


The routing protocol SHALL 
differentiate the routing 
information originated at a 
given-level RA from derived 
| routing information | 
| (received from external | 
| | 


RAs), even when this 
information is forwarded by 
another RC at the same 
level. 


provide a mechanism to 
prevent information 
propagated from a Level N+1 
RA’s RC into the Level N 
| RA’s RC from being | 
| re-introduced into the | 
| Level N+1 RA’s RC. | 
+ + 


+ + 
| The routing protocol MUST | Yes 
| | 
| | 


The routing protocol MUST 
provide a mechanism to 
| prevent information | 
|propagated from a Level N-1| 
| RA’s RC into the Level N | 
| RA’s RC from being | 
re-introduced into the 
Level N-1 RA’s RC. 


Standards Track 
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Instance of a Level N 

routing function and an 

instance of a Level N+1 

routing function in the 
same system. 

The Level N routing 
function is on a separate 
system than the Level 
N+1 routing function. 
The RC MUST support static 
(i.e., operator assisted) 
and MAY support automated 
configuration of the 
information describing its 
|relationship to its parent 
and its child within the 
hierarchical structure 
(including RA ID and RC 
ID). 


The RC MUST support static 
(i.e., operator assisted) 
and MAY support automated 

configuration of the 
information describing its 
associated adjacencies to 

other RCs within an RA. 

The routing protocol SHOULD 

support all the types of RC 

| adjacencies described in 
|Section 9 of [G.7715]. The 
| latter includes congruent 
| topology (with distributed 
RC) and hubbed topology 

(e.g., 
does not automatically 
imply a designated RC). 


Standards Track 


note that the latter 


January 201 


$ $ 

| Yes | Sections 2, 

| | 3, and 7. 

| | 

| | 

iris $ 

| Not described | N/A 

| but possible. | 

| | 

$ $ 

| The automation| Sections 2 

| requirement island 3. Refer 

| ambiguous. | to RFC 2328 

| OSPF supports for OSPF 

auto-discovery auto- 

| of neighbors | discovery. 

| and topology. | 

| Default and | 

| automatically | 

| configured | 

polices are 

| out of scope. | 

$ $ 

|Yes - when OSPF|RFC 2328 and 

larea maps to RA|Section 11.1. 

| discovery is | 

automatic. 

| | 

| | 

| | 

$ 4 === 385 
Yes RFC 2328. 

| | 

| | 

| | 

| | 

| | 

| | 

$ $ 
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| 3.4 (19) |The routing protocol SHOULD | Yes |RFC 2328, RFC| 
be capable of supporting 5250, and 
architectural evolution in Section 11.2. 


| | terms of the number of 
| |hierarchical levels of RAs, 
| las well as the aggregation 
| | and segmentation of RAs. 
3.5.2 (20) |Advertisements MAY contain 
[the following common set of 
| information regardless of 
whether they are link or 
node related: 

- RA ID of the RA to 
which the 
advertisement is 
bounded 

- RC ID of the entity 


| 
| 
| 
| 
+ 
| 
| 
| 
| 
| 
| Section 
| 
| 

generating the | 
| 
| 
| 
| 
| 
| 
| 
+ 


EA 


Yes 


| 
| 
| 
| Yes RFC 2328. 
| 
| advertisement 
- Information to Yes 
uniquely identify 5250. 
| advertisements 
| No - Must 
| compare to old. 
| 
| 
| 
| 
| 
+ 


- Information to 
determine whether an 
advertisement has 
been updated 

- Information to 
indicate when an 
advertisement has been 
derived froma 
different level RA. 


Section 
PQ sls 


| 

| 

| 

| 

| 

| 

| 

| 

RFC 2328, = 
| 

| 

| 

| 

Yes | 
| 

| 

| 

| 


5 _ _ n +» ——— 
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Re a ee A + 
RFC 5786, 

Sections 4 
and 6. 


3.5.3 (21) |The Node Attributes’ Node |yYes - Prefixes 
ID and Reachability must be only for 
advertised. It MAY be reachability. 
advertised as a set of 
associated external (e.g., 
User Network Interface 
(UNI)) address/address 
prefixes or a set of 
associated Subnetwork 
Point Pool (SNPP) link 
IDs/SNPP ID prefixes, the 
selection of which MUST be 
consistent within the 
applicable scope. 


A ae See at ee + 


[3.5.4 (22)| The Link Attributes’ Local Section 6.1. 
SNPP link ID, Remote SNPP 
link ID, and layer specific 
characteristics must be 


advertised. 


Section 5, 
RFC 4652 - 


Link Signaling Attributes 
| 
Section | 
| 
| 


other than Local Adaptation 
(Signal Type, Link Weight, 
Resource Class, Local 
Connection Types, Link 
Capacity, Link 
Availability, Diversity 
Support). 


Ds Dre les 


+ 
l 
l 
l 
l 
l 
l 
l 
l 
l 
l 
l 
l 
l 
l 
l 
l 
l 
l 
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l 
l 
l 
l 
l 
l 
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l 
l 
l 
l 
l 
l 
l 
l 
l 
l 
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l 
l 
l 
l 
l 

4 + 


Link Signaling Local Section Soia] 


Adaptation. 


Tai Sees el pd ll Spgs ii eet Ja pgs eel Geet ee + 
Sections 2, 
3, and 6. 


| 

+ 

| 

| 

+ 

The routing adjacency | 
topology (i.e., the | 
|associated PC connectivity | 
| 

| 

| 

+ 

| 

| 

| 

+ 


—— + —— + — 


[network topology SHALL NOT 
|be assumed to be congruent. 


| 
| 
| 
| |topology) and the transport 
| 
| 


b et a a a ta ned eos Se + 
RFC 2328, RFC| 


| 5 (26) |The routing topology SHALL 
3630. | 


support multiple links 
between nodes and RAs. 


+ 
l 
| 
l 
l 
| 
l 
| 
| 
| 

+ — 
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|The routing protocol SHALL 
converge such that the 
distributed Routing 
Databases (RDBs) become 


of time. 
Self-consistent information 
at the receiving level 
resulting from any | 
transformation (filter, | 
summarize, etc.) and | 
| 


forwarding of information 
from one RC to RC(s) at 
different levels when 
multiple RCs are bound to a 
Single RA. 


In order to support | 
operator-assisted changes | 
in the containment | 
relationships of RAs, the 
| routing protocol SHALL | 
|support evolution in terms | 
| of the number of | 
[hierarchical levels of RAs. | 
For example, support of 
non-disruptive operations 
|such as adding and removing| 
| RAs at the top/bottom of | 
| the hierarchy, adding or | 
| removing a hierarchical | 
level of RAs in or from the 
middle of the hierarchy, as 
well as aggregation and 
segmentation of RAs. 


| A collection of links and 
nodes such as a subnetwork 
or RA MUST be able to 
represent itself to the 
wider network as a single 
logical entity with only 
its external links visible 
to the topology database. 


+ + —— 
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RFC 2328, RFC] 
5250. 


Yes - However, Section 7.1. 
this is not a 
routing 
protocol 


function. 


Partial - OSPF |RFC 2328 and 
supports the RFC 5250. 
purging of 
stale 
advertisements 
and origination 
of new. The 
non-disruptive 
behavior is 
implementation 
specific. 


| 
| 
| 
| 
| 
ooo 4+-------------+ 
| 
| 
| 
| 
| 


| 
| 
| 
| 
| 
+ 
| 


Sections 4 
and 6. 


Yes - Within an 
RA it must be 
consistent. 
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Appendix A. ASON Terminology 
This document makes use of the following terms: 


Administrative domain: (See Recommendation [G.805].) For the 
purposes of [G.7715.1], an administrative domain represents the 
extent of resources that belong to a single player such as a 
network operator, a service provider, or an end-user. 
Administrative domains of different players do not overlap amongst 
themselves. 


Control plane: performs the call control and connection control 


functions. Through signaling, the control plane sets up and 
releases connections and may restore a connection in case of a 
failure. 


(Control) Domain: represents a collection of (control) entities that 
are grouped for a particular purpose. The control plane is 
subdivided into domains matching administrative domains. Within 
an administrative domain, further subdivisions of the control 
plane are recursively applied. A routing control domain is an 
abstract entity that hides the details of the RC distribution. 


External NNI (E-NNI): interfaces located between protocol controllers 
between control domains. 


Internal NNI (I-NNI): interfaces located between protocol controllers 
within control domains. 


Link: (See Recommendation G.805.) A "topological component" that 
describes a fixed relationship between a "Subnetwork" or "access 
group" and another "subnetwork" or "access group". Links are not 


limited to being provided by a single server trail. 


Management plane: performs management functions for the transport 
plane, the control plane, and the system as a whole. It also 
provides coordination between all the planes. The following 
management functional areas are performed in the management plane: 
performance, fault, configuration, accounting, and security 
management. 


Management domain: (See Recommendation G.805.) A management domain 
defines a collection of managed objects that are grouped to meet 
organizational requirements according to geography, technology, 
policy, or other structure, and for a number of functional areas 
such as Fault, Configuration, Accounting, Performance, and 
Security (FCAPS), for the purpose of providing control ina 
consistent manner. Management domains can be disjoint, contained, 
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or overlapping. As such, the resources within an administrative 
domain can be distributed into several possible overlapping 
management domains. The same resource can therefore belong to 
several management domains simultaneously, but a management domain 
shall not cross the border of an administrative domain. 


Subnetwork Point (SNP): The SNP is a control-plane abstraction that 
represents an actual or potential transport-plane resource. SNPs 
(in different subnetwork partitions) may represent the same 
transport resource. A one-to-one correspondence should not be 
assumed. 


Subnetwork Point Pool (SNPP): A set of SNPs that are grouped together 
for the purposes of routing. 


Termination Connection Point (TCP): A TCP represents the output of a 
Trail Termination function or the input to a Trail Termination 
Sink function. 


Transport plane: provides bidirectional or unidirectional transfer of 
user information, from one location to another. It can also 
provide transfer of some control and network management 
information. The transport plane is layered; it is equivalent to 
the Transport Network defined in Recommendation G.805. 


User Network Interface (UNI): interfaces are located between protocol 
controllers between a user and a control domain. Note: There is 
no routing function associated with a UNI reference point. 


Appendix B. ASON Routing Terminology 
This document makes use of the following terms: 


Routing Area (RA): an RA represents a partition of the transport 
plane, and its identifier is used within the control plane as the 
representation of this partition. Per [G.8080], an RA is defined 
by a set of subnetworks, the links that interconnect them, and the 
interfaces representing the ends of the links exiting that RA. An 
RA may contain smaller RAs inter-connected by links. The limit of 
subdivision results in an RA that contains two subnetworks 
interconnected by a single link. 


Routing Database (RDB): a repository for the local topology, network 
topology, reachability, and other routing information that is 
updated as part of the routing information exchange and may 
additionally contain information that is configured. The RDB may 
contain routing information for more than one routing area (RA). 
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Routing Components: ASON routing architecture functions. These 
functions can be classified as protocol independent (Link Resource 
Manager (LRM), Routing Controller (RC)) or protocol specific 


(Protocol Controller (PC)). 


Routing Controller (RC): handles (abstract) information needed for 
routing and the routing information exchange with peering RCs by 
operating on the RDB. The RC has access to a view of the RDB. 
The RC is protocol independent. 


Note: Since the RDB may contain routing information pertaining to 
multiple RAs (and possibly to multiple layer networks), the RCs 
accessing the RDB may share the routing information. 


Link Resource Manager (LRM): supplies all the relevant component and 
TE link information to the RC. It informs the RC about any state 
changes of the link resources it controls. 


Protocol Controller (PC): handles protocol-specific message exchanges 
according to the reference point over which the information is 
exchanged (e.g., E-NNI, I-NNI) and internal exchanges with the RC. 
The PC function is protocol dependent. 


Appendix C. Changes from RFC 5787 
This document contains the following changes from RFC 5787: 


1. This document will be on the Standards Track, rather than 
Experimental, and reflects experience gained from RFC 5787 
implementation and interoperability testing. This also required 
changes to the IANA Considerations. 


2. There is a new Section 3 on Terminology and Identification to 
describe the mapping of key ASON entities to OSPF entities. 


3. Sections were reorganized to explain terminology before defining 
prefix extensions. 


4. There is a new Section 11, Management Considerations, which 
describes how existing OSPF mechanisms address ASON requirements 
on Routing Area changes. 


5. There is a new Section 12, which compares the document to the 
requirements in RFC 4258. 


6. The prefix format was changed to reference RFC 5786 rather than 


defining a separate format and The Node Attribute TLV in RFC 5786 
has been updated as a result. 
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7. Routing Information Advertisements were simplified from RFC 5787. 

8. Review comments from ITU-T SG15 and the IESG were incorporated. 
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